1. Field of the Invention
The present invention relates to software tools for developing and executing interactive voice response (IVR) applications. More particularly, the present invention relates to software tools for developing and executing IVR applications that include data-dependent call flows.
2. Description of Background Art
Interactive voice response (IVR) systems enable a dialogue between a human caller (e.g., using a telephone) and a computer system so that the caller can direct the computer system to perform a task. People can use IVR systems to perform a variety of tasks, from selecting one of several menu options to performing financial transactions.
An IVR system usually comprises standard computer hardware and a speech-enabled (IVR) application. An IVR application, such as a telephone banking application, defines a call flow that controls the operation of the IVR system during a call. A call flow includes one or more steps. A step can be, for example, playing sounds to the caller, obtaining information from the caller, or performing an application-specific task.
A call flow frequently includes one or more variables. The value of a variable can affect the call flow, thereby affecting the operation of the IVR system. For example, the value can determine what sounds are played to the caller, whether a caller should be transferred, and to which number a caller should be transferred. Sometimes, when an IVR system begins operation (e.g., in response to an incoming phone call), a variable's value has not yet been specified. The value is specified during operation (e.g., during the phone call) and can be determined by, for example, caller input that has been recognized by a speech recognition engine. Since caller input affects the value and the value affects the operation of the IVR system, caller input affects the operation of the IVR system.
Initially, IVR applications were generally custom-designed for each customer. As a result, the design process was time-consuming and labor-intensive, and the applications required substantial pre-release testing. Recently, frameworks have been created for developing IVR applications, thus enabling less experienced people to create new IVR applications and modify existing ones. These frameworks generally include reusable software components that are represented by icons in a graphical display. The call flow of an application can be specified by connecting these icons, and the process steps represented by the icons can be modified by associating parameters with the underlying components.
Now that it is easier to create new IVR applications, it is also easier to create “broken” ones. Similarly, now that it is easier to modify existing applications, it is also easier to “break” existing ones. If the value of a particular variable affects a call flow, it follows that the value must be determined at some point during the operation of the IVR system. Usually, a call flow will include a component that determines the value of the variable (e.g., by obtaining information from a caller). Later on in the call flow, after the value has been obtained, it can be used by other components. One way to “break” an IVR application is by moving one of these “variable-reliant” components earlier in the call flow than the component that determines the value of the variable.
What is needed is an IVR system that can handle a call flow where a “variable-reliant” component precedes the determination of the value of that variable.